Workflow Condition Template

The Workflow Condition template demonstrates how a BindAI workflow can make a runtime decision and continue execution through one of two configured paths. A ConditionNode evaluates a predicate against the workflow context. Depending on whether the predicate returns True or False, the node adds the configured true or false node to the workflow execution queue. This template introduces conditional branching into BindAI workflows.

Purpose

This template demonstrates how to:

Add a ConditionNode to a workflow
Evaluate runtime workflow context
Define a true branch
Define a false branch
Route execution dynamically
Use workflow variables when implementing predicates

It extends the basic sequential workflow model with a decision point.

Workflow Structure

A conditional workflow can be represented conceptually as:

Previous Node
      |
      v
Condition
    /   \
 True   False
  |       |
  v       v
Node A   Node B

The ConditionNode itself does not contain the branch node implementations. Instead, it stores the identifiers of the nodes to execute when the predicate evaluates to True or False.

ConditionNode

The condition implementation is:

ConditionNode(
    node_id,
    predicate,
)

The predicate has the following conceptual signature:

Callable[[WorkflowContext], bool]

This means the predicate receives the current workflow context and must return a Boolean value. For example:

def is_approved(context):
    return context.variables.get("approved") is True

The condition can then be created with:

condition = ConditionNode(
    "check-approval",
    is_approved,
)

Defining the Branches

The true and false branches are configured explicitly.

condition.when_true(approved_node)
condition.when_false(rejected_node)

Both methods return the condition node itself, allowing chained configuration:

condition = (
    ConditionNode("check-approval", is_approved)
    .when_true(approved_node)
    .when_false(rejected_node)
)

The condition stores the IDs of the configured nodes.

Execution Flow

When the workflow executor reaches a ConditionNode, it calls:

node.execute(context)

The condition evaluates its predicate:

Condition
    |
    v
Evaluate Predicate
    |
    +---- True ----> Queue True Node
    |
    └---- False ---> Queue False Node

The selected node is added to the workflow execution queue. The workflow executor then continues processing nodes from that queue.

Decision Logic

The condition itself does not require a specific business rule. The predicate determines the decision. For example:

def is_approved(context):
    return context.variables.get("approved") is True

The condition can then route execution based on that value:

approved == True
       |
       v
Approved Node

or:

approved == False
       |
       v
Rejected Node

The predicate can inspect any information available through the workflow context.

Workflow Context

The predicate receives the workflow context:

def predicate(context):
    ...

This provides access to the workflow’s runtime state. A common pattern is to inspect workflow variables:

def is_approved(context):
    return context.variables.get("approved") is True

A previous node may populate the variable:

context.variables["approved"] = True

The condition can then use that value to determine the next execution path. The exact variables available depend on the nodes and application logic in the workflow.

Example

Suppose a previous node determines whether a request should be approved.

def is_approved(context):
    return context.variables.get("approved") is True


condition = (
    ConditionNode(
        "approval-check",
        is_approved,
    )
    .when_true(approval_node)
    .when_false(rejection_node)
)

The resulting execution conceptually looks like:

Analyze Request
      |
      v
Condition
   /      \
True      False
 |          |
 v          v
Approve    Reject

If approved is True, the approval node is queued. If approved is not True, the rejection node is queued.

Branch Configuration

A true branch is configured with:

condition.when_true(node)

A false branch is configured with:

condition.when_false(node)

Both branches are optional at the ConditionNode level. If the predicate evaluates to True but no true node has been configured, no true-branch node is added to the execution queue. Likewise, if the predicate evaluates to False but no false node has been configured, no false-branch node is added. For predictable workflows, configure the branch paths that the workflow is expected to use.

Branching Example

A common approval workflow might look like:

Receive Request
       |
       v
Evaluate Request
       |
       v
Approval Condition
      / \
     /   \
    v     v
Approve  Reject

The condition separates the decision from the actions performed after the decision. This allows the workflow structure to express the business process explicitly.

Agent Integration

An agent can produce information that a later condition evaluates. For example:

User Request
     |
     v
Agent
     |
     v
Workflow Variables
     |
     v
Condition

The agent and condition have separate responsibilities:

The agent performs AI-driven work.
The workflow condition evaluates runtime state.
The selected branch determines what executes next.

The exact mechanism used to populate variables depends on the agent node and surrounding workflow implementation. A ConditionNode itself does not perform AI reasoning.

Conditions and Workflow Orchestration

Conditions are useful when a workflow needs deterministic orchestration around runtime data. For example:

Input
  |
  v
Process
  |
  v
Condition
 /      \
Low     High
 |        |
 v        v
Path A   Path B

The decision is represented explicitly in the workflow rather than being hidden inside a prompt. This can make workflow behavior easier to inspect and test.

Common Use Cases

Conditional workflows can be useful for:

Approval decisions
Validation results
Eligibility checks
Request routing
Escalation decisions
Status-based processing
Threshold checks
Classification results
Business-rule evaluation

The predicate can implement the rule appropriate for the workflow.

Predicate Design

A predicate should return a Boolean value:

def should_escalate(context):
    return context.variables.get("risk") == "high"

Avoid making the predicate responsible for performing large amounts of workflow work. A useful separation is:

Previous Node
    |
    | produces data
    v
Workflow Context
    |
    | predicate reads data
    v
Condition
    |
    | selects path
    v
Next Node

The condition’s responsibility is to make the routing decision.

Condition vs Prompt Logic

Conditions are useful for deterministic workflow routing.

Prompt-based decision	Workflow condition
Decision is part of model output	Decision is represented by a Python predicate
Behavior depends on model reasoning	Behavior depends on the predicate
Harder to test as orchestration	Predicate can be tested directly
Routing may be implicit	Branch routing is explicit

This does not mean prompts should never contain reasoning. Rather, ConditionNode provides a clear mechanism for deterministic orchestration around runtime state.

Combining Conditions

Multiple conditions can be used in the same workflow. For example:

Start Logic
    |
    v
Condition A
  /    \
 A1    A2
 |      |
 v      v
Condition B
  /    \
 B1    B2

Each condition evaluates its own predicate and queues the configured branch node. Complex decision trees should be kept understandable and tested across their possible paths.

Testing Both Branches

A condition should be tested with context values that exercise both outcomes. For example:

def is_approved(context):
    return context.variables.get("approved") is True

Test with:

context.variables["approved"] = True

and:

context.variables["approved"] = False

This verifies that both branch paths are configured correctly. It is also useful to test the behavior when an expected variable is missing.

Current Implementation Details

The current ConditionNode implementation:

class ConditionNode(WorkflowNode):
    ...

maintains:

self.predicate
self.true_node
self.false_node

The branch methods store node IDs:

condition.when_true(node)
condition.when_false(node)

During execution:

if self.predicate(context):
    ...
else:
    ...

The selected branch node ID is appended to:

context.execution_queue

The condition returns the workflow context after making the routing decision.

Important Boundaries

No built-in Start Node

A condition workflow does not require a special StartNode. The workflow’s first added node becomes its starting node.

No built-in End Node

A condition workflow does not require a special EndNode. The workflow completes according to the normal workflow executor rules after the execution queue is exhausted or another terminal execution condition occurs.

The predicate receives the context

The condition does not receive a single variable value automatically. The predicate receives the complete WorkflowContext and decides what information to inspect.

Branches are node references

when_true() and when_false() store the identifiers of the selected nodes. They do not execute those nodes immediately. The workflow executor processes the queued node afterward.

Missing branches are possible

A true or false branch may be left unset. In that case, the corresponding branch does not add a node to the execution queue.

Best Practices

Keep predicates focused on the routing decision.
Read runtime data from the workflow context.
Use descriptive node identifiers.
Configure both branches when both outcomes are meaningful.
Test both true and false outcomes.
Test missing or unexpected context values.
Keep complex business logic outside the condition when possible.
Use multiple conditions carefully so the workflow remains understandable.
Prefer explicit workflow routing over hidden orchestration logic.

The condition pattern builds on the basic workflow model introduced in:

08.1 workflow-basic.md

It can be combined with:

08.3 workflow-loop.md
08.4 workflow-parallel.md
08.5 workflow-human.md
08.6 workflow-retry.md
08.7 workflow-timeout.md
08.8 workflow-schedule.md

Conditions are particularly useful when combined with other workflow capabilities to create decision-driven automation.

Summary

The Workflow Condition template introduces deterministic branching into BindAI workflows. The essential pattern is:

Previous Node
      |
      v
ConditionNode
   /       \
True       False
 |           |
 v           v
Node A      Node B

A ConditionNode receives a predicate operating on the workflow context. The predicate returns True or False, and the condition adds the corresponding configured node to the workflow execution queue. This provides an explicit mechanism for routing workflow execution based on runtime state.

Getting Started

Core

Tools

Memory

Knowledge

Workflows

Projects

Templates

Connections

API Reference

Automation

Roadmap

08.2 workflow condition

Workflow Condition Template

Purpose

Workflow Structure

ConditionNode

Defining the Branches

Execution Flow

Decision Logic

Workflow Context

Example

Branch Configuration

Branching Example

Agent Integration

Conditions and Workflow Orchestration

Common Use Cases

Predicate Design

Condition vs Prompt Logic

Combining Conditions

Testing Both Branches

Current Implementation Details

Important Boundaries

No built-in Start Node

No built-in End Node

The predicate receives the context

Branches are node references

Missing branches are possible

Best Practices

Summary

​Workflow Condition Template

​Purpose

​Workflow Structure

​ConditionNode

​Defining the Branches

​Execution Flow

​Decision Logic

​Workflow Context

​Example

​Branch Configuration

​Branching Example

​Agent Integration

​Conditions and Workflow Orchestration

​Common Use Cases

​Predicate Design

​Condition vs Prompt Logic

​Combining Conditions

​Testing Both Branches

​Current Implementation Details

​Important Boundaries

​No built-in Start Node

​No built-in End Node

​The predicate receives the context

​Branches are node references

​Missing branches are possible

​Best Practices

​Related Templates

​Summary

Workflow Condition Template

Purpose

Workflow Structure

ConditionNode

Defining the Branches

Execution Flow

Decision Logic

Workflow Context

Example

Branch Configuration

Branching Example

Agent Integration

Conditions and Workflow Orchestration

Common Use Cases

Predicate Design

Condition vs Prompt Logic

Combining Conditions

Testing Both Branches

Current Implementation Details

Important Boundaries

No built-in Start Node

No built-in End Node

The predicate receives the context

Branches are node references

Missing branches are possible

Best Practices

Related Templates

Summary